Documento de Análisis de riesgos

Ingeniería del Software y Práctica Profesional - Universidad de Sevilla

BERMEJO SORIA, CARLOS

CASAL FERRERO, RUBÉN

DOMÍNGUEZ RUIZ. ANDRÉS

DOMÍNGUEZ-ADAME RUIZ. ALBERTO

FERNÁNDEZ CASTILLO, JAVIER

GALLARDO MARTOS, DANIEL

HERRERA RAMIREZ, ISMAEL

IZQUIERDO LAVADO, MARIO

MATEOS GÓMEZ, FERNANDO JOSÉ

MERINO PALMA, ALEJANDRO JOSÉ

MONTERO MARTÍNEZ, FRANCISCO JESÚS

LÓPEZ MOYANO, ROCÍO

OTERO BARBASÁN, MANUEL

VILAPLANA DE TRÍAS, FRANCISCO DAVID

ZARZUELA REINA, CARLOS

Sevilla, Mayo 2024

Entregable: WPL

Grupo 01 (Mañana) - IT Talent

Control de Versiones

Versión	Fecha	Autor	Cambios
v1.0	14/02/2024	Alberto	Documento inicial

Resumen del documento

Este documento está destinado a identificar los posibles riesgos a ocurrir durante el desarrollo del proyecto, analizarlos para conocer su impacto y probabilidad de ocurrencia, y a desarrollar un plan de contingencia para evitar y/o mitigar el impacto del mismo.

Índice

Índice 3

1. Identificación de riesgos 4

2. Análisis de riesgos 5

3. Monitorización de riesgos 7

1. Identificación de riesgos

   Aquí se identifica una lista de posibles riesgos que pueden ocurrir debido a la naturaleza del proyecto:

• Limitaciones de la API de GitHub: La API pública de GitHub podría tener limitaciones en términos de acceso, frecuencia de las solicitudes o cambios en su estructura. Es importante tener en cuenta estas limitaciones y asegurarse de cumplir con las políticas de uso para evitar bloqueos o restricciones.
• Protección de la privacidad y regulaciones: un cambio en las leyes de uso y privacidad de datos podría obligarnos a detener la aplicación para actualizarla. Esto resultaría en un gasto de tiempo y dinero fuera de los costes estimados.
• Seguridad de la aplicación: las medidas de seguridad podrían no ser adecuadas para proteger los datos recopilados y la información del usuario (no estar protegido contra inyecciones SQL, ataques maliciosos, etc.).
• Riesgos tecnológicos: no todos los miembros de la organización tienen experiencia con las tecnologías elegidas para el desarrollo.
• Requisitos cambiantes: el cambio de un requisito ya en fase de desarrollo podría ser muy laborioso.
• Errores en diseño: puede darse que el diseño de la aplicación muestre errores o no sea escalable si en un futuro fuera necesario adaptar la aplicación a un mayor volumen de usuarios (se planeó mal o se fue definiendo a medida que se avanzaba).
• Pruebas del sistema insuficientes: Una falta de pruebas relevantes podría no desvelar errores importantes o no asegurar un rendimiento adecuado.
• Baja calidad: la baja calidad del trabajo, ya sea en el análisis como en el código, puede dar lugar a una multitud de problemas: errores de diseño, implementación, seguridad, rendimiento, en los ciclos de desarrollo, etc.
• Baja productividad: Algunos miembros del grupo podrían no llegar a cumplir con el trabajo asignado a tiempo. Para ello se ha redactado y firmado el Acuerdo de Compromiso (Commitment Agreement)
• Falta de comunicación: Una falta o mala comunicación puede dar lugar a muchos problemas: malentendidos de requisitos, confusión en expectativas, problemas de coordinación, etc.
• Falta de cumplimiento del commitment agreement: Si alguna de las cláusulas establecidas en el commitment agreement no se cumpliera por uno o más miembros del grupo.
• Cambio en los costes: Los costes de las tecnologías y APIs** usadas (como Github) podrían cambiar con el tiempo.
• Más horas de las previstas: Si de forma consistente los integrantes del grupo tardaran en completar su trabajo más horas de las estimadas**.
• Nuevos competidores en el mercado: Pueden surgir nuevos competidores que hagan lo mismo que nosotros y tomen cuota de mercado, lo cual reduciría la nuestra.
• Alcance de clientes: Si no somos capaces de llegar como mínimo a la cantidad de usuarios necesarios, podríamos pasar desapercibidos, lo que implicaría menos ingresos.
• Análisis de costes erróneos: Una variación en los costes puede ser desastrosa para cualquier proyecto.
• Precios no adecuados: Unos precios que no correspondan al servicio que el usuario espera podría hacer que disminuyera la cantidad de suscripciones esperadas.
• APIs caídas: Si los servicios de los que dependen nuestro producto no están disponibles, nuestro producto dejaría de funcionar.
• Experiencia de usuario pobre: Si el usuario no se siente cómodo navegando por nuestra aplicación, podría derivar en un abandono de esta.
• Plan personalizado sin éxito: El plan personalizado podría atraer pocos clientes, resultando en menos ingresos de los esperados.

1. Análisis de riesgos

Id	Problema	Prob. de ocurrencia	Impacto	Factor	Prioridad	Plan de Contingencia
R1	Limitaciones de la API de GitHub	7	8	56	10	Adaptar nuestro uso de la API a las limitaciones y cambios. Los responsables serán los coordinadores.
R2	Cambios en las leyes de protección de datos	6	9	54	9	Mantener una política de privacidad y uso de datos actualizada acorde a las leyes. Los responsables serán los coordinadores.
R3	Falta de seguridad de la aplicación	6	7	42	9	Implementar nuevas bibliotecas de seguridad y/o diseñar nosotros mismos algoritmos de seguridad. Los responsables serán los analistas.
R4	Tecnología desconocida por los miembros del grupo	3	3	9	4	Proporcionar capacitación adicional a los miembros del equipo para cerrar las brechas de conocimiento. Los responsables serán los coordinadores.
R5	Requisitos cambiantes	8	7	40	10	Adaptar el código para representar los requisitos cambiados. Los responsables serán los analistas y los programadores.
R6	Errores en diseño	5	8	40	8	Revisar el diseño y modificarlo adecuadamente. Los responsables serán los analistas.
R7	Pruebas del sistema insuficientes	3	7	21	8	Diseñar un conjunto de pruebas que cubran todos los aspectos críticos del sistema. Los responsables serán los programadores encargados de testing.
R8	Baja calidad	6	9	54	10	Replantear la forma de realizar el trabajo (reparto de tareas y grupos). Los responsables serán los coordinadores.
R9	Baja productividad	5	5	25	3	Ajustar las asignaciones de trabajo si es necesario y aplicar las cláusulas del commitment agreement. El responsable será el coordinador del subgrupo.
R10	Falta de comunicación	6	8	48	7	Establecer canales de comunicación claros. El responsable será el coordinador de cada subgrupo
R11	Falta de cumplimiento del commitment agreement	5	8	40	7	Deberán aplicarse las recompensas y penalizaciones establecidas en el commitment agreement. Los responsables serán los coordinadores.
R12	Cambio en los costes	7	9	63	8	Se adaptarán los costes y los precios adecuadamente. El responsable será el equipo de marketing.
R13	Más horas de las previstas	5	7	35	6	Se reducirá el alcance del proyecto. Los responsables serán los coordinadores.
R14	Nuevos competidores en el mercado	6	7	42	5	Buscar nuevas formas de diferenciarnos de la competencia. Los responsables serán los analistas y marketing
R15	Alcance de clientes	7	6	42	7	Solicitar feedback a los clientes y reevaluar los objetivos de la aplicación
R16	Análisis de costes erróneos	3	6	18	2	Se usarán los gastos destinados a cobertura. Si fuera necesario habría que ajustar los precios de la App. El responsable será el equipo de marketing.
R17	Precios no adecuados	5	8	40	7	Realizar un nuevo estudio del mercado y ajustar los precios. Los responsables serán marketing
R18	APIs caídas	2	10	20	10	Contactar con el soporte técnico de GitHub y/o buscar alternativas. Los responsables serán los coordinadores.
R19	Experiencia de usuario pobre	4	8	32	7	Solicitar feedback a los usuarios y replantear el diseño de la app. El responsable será el equipo de diseño
R20	Plan personalizado sin éxito	5	6	30	6	Cambiar el plan por uno de precio fijo, pero con features personalizables (el precio varía en función de esto). El responsable será el equipo de marketing.

Estas son unas estimaciones iniciales, y tendrán que ser ajustadas a medida que avance el proyecto.

1. Monitorización de riesgos

Id	Descripción de la monitorización	Encargado	Métrica (mide la efectividad de las acciones correctivas)
R1	Revisar regularmente las actualizaciones y cambios en la API de GitHub.	Los coordinadores	No procede.
R2	Revisar regularmente las actualizaciones y cambios en la ley de protección de datos.	Los coordinadores	No procede.
R3	La seguridad se comprobará mediante pruebas (testing) y herramientas de evaluación de seguridad como OWASP ZAP o OpenVas.	Equipo de Testing	La cobertura de las pruebas y los resultados de las herramientas de evaluación de seguridad.
R4	Se hará un cuestionario sobre el conocimiento de las tecnologías a usar y se elaborará un plan de aprendizaje de las mismas si es necesario.	Los coordinadores	Comparar la calidad del código antes y después de la formación.
R5	Se revisarán los requisitos a medida que avance el proyecto de forma regular.	Los analistas	No procede.
R6	A medida que avance el proyecto se revisará la arquitectura con respecto a lo implementado.	Los analistas	No procede.
R7	Se comprobará regularmente la cobertura de las pruebas realizadas.	Equipo de Testing	La cobertura de las pruebas antes y después del riesgo.
R8	El trabajo realizado por cada subgrupo es revisado por uno o más de los coordinadores.	Los coordinadores	No procede.
R9	Se vigilará el trabajo realizado y las horas dedicadas a dicho trabajo regularmente.	Los coordinadores	La cantidad de trabajo por tiempo realizado
R10	Se realizarán cuestionarios sobre satisfacción en la comunicación.	Los coordinadores	No procede
R11	Se vigilará el trabajo realizado y las horas dedicadas a dicho trabajo regularmente.	Los coordinadores	Número de faltas cometidas en total
R12	Se vigilarán periódicamente los costes de las tecnologías usadas.	El equipo de marketing	Las ganancias obtenidas
R13	Se mantendrá bajo observación la herramienta de seguimiento del tiempo, el Clockify	Los coordinadores	Las horas trabajadas por semana
R14	Observar el mercado siempre en busca de nueva competencia.	El equipo de marketing	El número de clientes antes y después de realizar los cambios que nos diferencien de la competencia.
R15	Hacer un estudio que asegure que nuestro principal producto tenga un público sustancial.	Equipo de análisis	El número de clientes antes y después.
R16	Se realizará un exhaustivo estudio de los costes esperados.	Equipo de marketing	No procede
R17	Se vigilará la competencia en el mercado, sus precios y nuestros costes para determinar los precios adecuados.	Equipo de marketing	Comparar el número de clientes medio de clientes con los nuevos precios.
R18	Revisar diariamente el correcto funcionamiento de la API y las actualizaciones de GitHub.	Equipo de mantenimiento	No procede
R19	Solicitar feedback de los usuarios pilotos para evitar una mala experiencia a los usuarios finales.	El equipo de análisis	Comparar el feedback de los usuarios pilotos
R20	Se monitorizará los clientes con plan personalizado comparado con los esperados.	Equipo de marketing	Clientes con el plan personalizado